@avishorp
Hello
What is the reason for not storing segment data in the class?
Looking at this pull request, it looks like we need to have the segment data in the class.
TM1637 can control only 6 digits with one. ..

By "segment data" -- do you mean the digit ordering/remapping?

My thought was that someone might want to use a different remapping? But you're right; being that the only two displays that people here seem to use are the 4 digit display which works "out of the box" and the 6 digit with its odd remapping, i can rework it to include that remapping as a default.

(sidenote, i also now have a "print text" function that I use in mine with a nearly-full font of sorts to print arbitrary text to the display... I'll submit a push request for that soon... pics of it on my twitter https://twitter.com/yorgle )

@BleuLlama
#83 (comment)

The library is designed in such a way that it does not store the value (or segment values) to be displayed, it just sends them to the display module once the application requests.

I've written a comment here for the author @avishorp of this library, not a comment for you. I'm sorry it's complicated.
He says, "I'm designing a class that doesn't hold segment data," so I asked him for a good reason in this draft.
Your fix holds the data for remapping in the class. So why not keep the segment data in the class? I thought.
If I connect multiple TM1637s, can I control more than 7 digits? I look at the datasheet.

Actually, my code doesn't keep the remapping data in the class, just a pointer to the ordering array, and it's optional at that. If you initialize 6 of these they can all point at the same array without duplication of the array etc. But i understand your question/concern now. I can make any changes needed to make my updated functionality fit better with the goals of the main author, if so desired.

Is anything happening with this PR? I just tried it after failing to get a Robotdyn 6 digit display working with the base version and it works perfectly.